Management of virtual goods in a blockchain-ledger based gaming architecture

ABSTRACT

Various embodiments provide management of virtual goods. In some embodiments, a gaming platform can be used to provide a secure ledger system for recording money transfer, play action, bets, analytics, gaming statistics, and the like, which are associated with virtual goods. Non-limiting examples of virtual goods comprise: characters; badges/icons; gameplay attributes; virtual money; cryptocurrencies; tokens; digital gifts; gameplay levels/add-ons; and prizes, among other examples. In some examples, gaming systems can directly interact with the distributed multi-ledger architecture for secure and transparent transactions which can also be accessed by auditors, tax authorities, partners, and/or other entities. Some examples may use private and/or public blockchains as part of the distributed multi-ledger gaming architecture. For instance, multiple distributed network nodes may be utilized to manage transaction records.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/365,157 filed on Mar. 26, 2019, and issued as U.S. Pat. No.10,832,522 on Nov. 10, 2020; which is a divisional of U.S. patentapplication Ser. No. 16/176,864 filed on Oct. 31, 2018, and issued asU.S. Pat. No. 10,614,661 on Apr. 7, 2020; which claims the benefit ofand priority to U.S. Provisional Patent Application No. 62/579,661 filedon Oct. 31, 2017, U.S. Provisional Patent Application No. 62/616,247filed on Jan. 11, 2018, and U.S. Provisional Patent Application No.62/738,619 filed on Sep. 28, 2018, each of which is hereby incorporatedby reference in its entirety for all purposes.

TECHNICAL FIELD

Various embodiments of the technology relate generally to gamingsystems. More specifically, some embodiments of the technology relate tosystems and methods for management of virtual goods in a distributedmulti-ledger gambling architecture.

BACKGROUND

Gaming systems/services manage ledgers and books to keep transactionalrecords. For instance, gaming systems/services enable users to executebets through a gaming environment. However, bets can be difficult totrack through execution, especially in instances where a long period oftime lapses between the time when a bet is created and when an outcomeis determined. This can make wagers more susceptible to having issuessuch as records being lost or instances where electronic records arehacked and tampered with. Additionally, records for gamingapplications/services are typically stored in a centralized database,greatly increasing the risk of data loss and financial loss via a datahack.

Other technical shortcomings of traditional gaming applications/servicesinclude limited user interfaces, where traditional gaming userinterfaces limit users on the types of bets that can be entered (e.g.,money wagers in a blackjack or poker application). Traditional gamingapplications/services do not allow users to enter customized betsenabling users to customize: wagers (e.g., physical goods, virtualgoods); conditions, parameters associated with the bet; and/or selectingvarious means of validation, among other examples. For maintainingledgers of transactional activity, such traditional practices may alsolead to less accurate transactional records that do not adequatelyreflect the nature of a specific bet.

SUMMARY

In view of the foregoing technical shortcomings, non-limiting examplesof the present disclosure relate to management of virtual goods throughan electronic gaming application/service. Transactions related tovirtual goods may be managed using a transaction ledger that isassociated with a gaming platform. In accordance with variousembodiments, a transparent gaming platform can be used to provide asecure ledger system for recording money transfer, play action, bets,analytics, gaming statistics (e.g., payouts, skill levels, etc.), andthe like, which are associated with virtual goods. Non-limiting examplesof virtual goods comprise: characters; badges/icons; gameplayattributes; virtual money; cryptocurrencies; tokens; digital gifts;gameplay levels and add-ons; and prizes, among other examples. Furtherexamples of virtual goods comprise but are not limited to: acryptocurrency, a paint job, a cosmetic, an article of clothing, adigital attribute, a digital item, a virtual item, a crypto collectable,or a non-fungible token. In some examples, gaming systems can directlyinteract with the distributed multi-ledger architecture for secure andtransparent transactions which can also be accessed by auditors, taxauthorities, partners, and/or other entities. Some examples may useprivate and/or public blockchains as part of the distributedmulti-ledger gaming architecture. For instance, multiple distributednetwork nodes may be utilized to manage creation, modification andaccess for transaction records.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of the presenttechnology may be realized by reference to the remaining portions of thespecification and the drawings wherein like reference numerals are usedthroughout the several drawings to refer to similar components. Further,various components of the same type may be distinguished by followingthe reference label with a dash and a second label that distinguishesamong the similar components. If only the first reference label is usedin the specification, the description is applicable to any one of thesimilar components having the same first reference label irrespective ofthe second reference label.

Embodiments of the present technology will be described and explainedthrough the use of the accompanying drawings as follows.

FIG. 1 illustrates an environment where an interactive gaming systemwith a distributed multi-ledger architecture can be used according tosome embodiments of the present technology.

FIG. 2 is a block diagram illustrating a distributed multi-ledger gamingarchitecture that may be used according to embodiments of the presenttechnology.

FIG. 3 illustrates various components of a skill-based gamingarchitecture utilizing a distributed multi-ledger architecture accordingto various embodiments of the present technology.

FIG. 4 illustrates an example of a computing platform that may be usedin accordance with some embodiments of the present technology.

FIG. 5 illustrates an example of gaming clients and/or the gamingservers interacting directly with the blockchain to verify or otherwiseobtain attributes of a virtual good during the course of a gameaccording to various embodiments of the present technology.

FIG. 6 illustrates various components of an example gaming platformutilizing a distributed multi-ledger architecture to manage virtualgoods according to various embodiments of the present technology.

FIG. 7 illustrates an example of various components of a gaming clientaccording to one or more embodiments of the present technology.

FIGS. 8A-8C illustrates an example of sets of operations for utilizationof a distributed multi-ledger architecture for the management of gamingactivity in accordance with some embodiments of the present technology.

FIG. 9 illustrates an example of transaction recordation within ablockchain according to some embodiments of the present technology.

FIG. 10 illustrates an example of a tamper evident log that may be usedin accordance with various embodiments of the present technology.

FIGS. 11A-11B illustrate examples of sets of operations for creation andmanagement of customized bets in accordance with various embodiments ofthe present technology.

FIG. 12 illustrates an example of information that may be recorded in amulti-ledger system in accordance with one or more embodiments of thepresent technology.

FIG. 13 illustrates an example of a graphical user interface that may beused for selecting games in accordance with some embodiments of thepresent technology.

FIG. 14 illustrates an example of a graphical user interface that may beused for selecting options to identify suitable games in accordance withvarious embodiments of the present technology.

FIG. 15 illustrates an example of a graphical user interface for showingavailable games in accordance with one or more embodiments of thepresent technology.

FIG. 16 illustrates various examples of graphical user interfacesshowing lobbies for various games according to some embodiments of thepresent technology.

FIG. 17 illustrates an example of a graphical user interface and systemfor creating customized bets that may be stored and automaticallyexecuted within a distributed multi-ledger system according to variousembodiments of the present technology.

FIG. 18 illustrates an example of a computing platform that may be usedin accordance with some embodiments of the present technology.

The drawings have not necessarily been drawn to scale. Similarly, somecomponents and/or operations may be separated into different blocks orcombined into a single block for the purposes of discussion of some ofthe embodiments of the present technology. Moreover, while thetechnology is amenable to various modifications and alternative forms,specific embodiments have been shown by way of example in the drawingsand are described in detail below. The intention, however, is not tolimit the technology to the particular embodiments described. On thecontrary, the technology is intended to cover all modifications,equivalents, and alternatives falling within the scope of the technologyas defined by the appended claims.

DETAILED DESCRIPTION

Non-limiting examples of the present disclosure relate to management ofvirtual goods through an electronic gaming application/service.Transactions related to virtual goods may be managed using a transactionledger that is associated with a gaming platform. In accordance withvarious embodiments, a transparent gaming platform can be used toprovide a secure ledger system for recording money transfer, playaction, bets, analytics, gaming statistics (e.g., payouts, skill levels,etc.), and the like, which are associated with virtual goods.Non-limiting examples of virtual goods comprise: characters;badges/icons; gameplay attributes; virtual money; cryptocurrencies;tokens; digital gifts; gameplay levels and add-ons; and prizes, amongother examples. Further examples of virtual goods comprise but are notlimited to: a cryptocurrency, a paint job, a cosmetic, an article ofclothing, a digital attribute, a digital item, a virtual item, a cryptocollectable, or a non-fungible token. In some examples, gaming systemscan directly interact with the distributed multi-ledger architecture forsecure and transparent transactions which can also be accessed byauditors, tax authorities, partners, and/or other entities. Someexamples may use private and/or public blockchains as part of thedistributed multi-ledger gaming architecture. For instance, multipledistributed network nodes may be utilized to manage creation,modification and access for transaction records.

Various transactions or other information such as bets, money transfers,records of game play, digital currency, loyalty information, avatars,bots, game states, jackpot amounts, and other transactions may berecorded on the blockchain. In some instances, executable code (e.g.,code written in Python, Pascal, C, C++, C#, Java, etc.), may be storedin the ledger that allows the gaming system to retrieve the most recentversion of the game. The blockchain can provide a chronologicalrecording of these various transactions or code in a ledger that can bedistributed across multiple nodes in a network. As such, these nodes caneach keep a copy of the transactions or code.

The present disclosure relates to implementation of a blockchainprotocol that secures a distributed ledger (e.g., blockchain ledger) forrecordation of transactional data related to virtual goods through agaming platform. As an example, a player (or group of players) mayattempt to access a virtual good associated with a player account. Forinstance, the player may be attempting to access a character, attribute,reward, etc., through gameplay of an online game (e.g., multiplayerfirst-person shooter or role-playing game). A gaming application/servicemay be configured to utilize a secure ledger (e.g., blockchain ledger)to validate a state of the virtual good, for example, to enable useraccess during gameplay. In another example, a player may create acustomized online bet that wagers a virtual good. A record oftransactional data for the customized online bet may be created andincorporated into a block of a blockchain ledger for managing thevirtual good through completion of the bet. In yet another example, astate of a virtual good may be updated, for example, based on winning abet, achieving a reward in gameplay, in-game purchase, etc.Transactional data related to a state of the virtual good may be managedthrough a secure blockchain ledger.

A gaming platform may maintain a ledger for a specific type of gamingapplication/service, where a ledger may be created for a specific gameor alternatively pertain to multiple different games. In instances whereledgers are maintained for individual games, a gaming platform maymaintain multiple ledgers for a plurality of games. Separate ledgers mayalso be created for different types of gaming transactions occurringthrough a gaming platform. In some embodiments, the ledger can be usedto create, record, and enforce customized bets between multiple parties(e.g., two or more parties). For example, if two parties would like tobet on an event, this bet can be recorded within the ledger. Theparticipants can agree on wager, outcome conditions, validation source,rules, and other conditions or parameters. In some embodiments, theledger may include code snippets that when executed evaluate the outcomeand automatically transfer money as set forth with the conditions of thebet. By writing the wagering amounts, rules, outcomes, verificationdetails, and the like into the ledger (e.g., a block in a blockchain)the bet can be tracked and verified.

Exemplary technical advantages provided by processing described in thepresent disclosure including but are not limited to: generation andmanagement of customized transactions executed through a gamingapplication/service; improved management of virtual goods andtransaction data for virtual goods through blockchain ledger(s);improved electronic record keeping for varying types of gamblingtransactions; an improved graphical user interface for gamingapplications/services to foster better management of customizedtransactions executed through a gaming application/service; improvedsecurity for system and services examples including management oftransactions through a gaming application/service; reduction incomputational complexity and computing resources (e.g., physicalcomputing devices and storage devices) necessary to validatetransactions through a gaming application/service; an exemplaryconsensus evaluation that provides a consolidated and consistent datasetwith reduced errors for in transaction recordation, improvedtransparency in data access transactions through implementation ofblockchain ledgers; improving resource tracking including the trackingand management of virtual goods associated with a gamingapplication/service; and improved processing efficiency (e.g., betterresource management) for management of transactions of a gamingapplication/service, among other examples.

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of embodiments of the present technology. It will beapparent, however, to one skilled in the art that embodiments of thepresent technology may be practiced without some of these specificdetails. While, for convenience, embodiments of the present technologyare described with reference to interactive gaming and customizedbetting on various devices, embodiments of the present technology areequally applicable to various other cloud-based gaming technologies.

The techniques introduced here can be embodied as special-purposehardware (e.g., circuitry), as programmable circuitry appropriatelyprogrammed with software and/or firmware, or as a combination ofspecial-purpose and programmable circuitry. Hence, embodiments mayinclude a machine-readable medium having stored thereon instructionswhich may be used to program a computer (or other electronic devices) toperform a process. The machine-readable medium may include, but is notlimited to, floppy diskettes, optical discs, compact disc read-onlymemories (CD-ROMs), magneto-optical discs, ROMs, random access memories(RAMs), erasable programmable read-only memories (EPROMs), electricallyerasable programmable read-only memories (EEPROMs), magnetic or opticalcards, flash memory, or other type of media/machine-readable mediumsuitable for storing electronic instructions.

The phrases “in some embodiments,” “according to some embodiments,” “inthe embodiments shown,” “in other embodiments,” and the like generallymean the particular feature, structure, or characteristic following thephrase is included in at least one implementation of the presenttechnology, and may be included in more than one implementation. Inaddition, such phrases do not necessarily refer to the same embodimentsor different embodiments.

FIG. 1 illustrates an environment where an interactive gaming systemwith a distributed multi-ledger architecture can be used according tosome embodiments of the present technology. As illustrated in FIG. 1 ,gaming terminals 110A-110D (e.g., mobile devices, gaming cabinets, tabletops, etc.) can be used by players 120A-120D) can allow various types ofgames to be played within a casino, local property, or other location.Various embodiments of the present technology allow for a variety ofgames including, but not limited to, networked games, interactive games,games of skill, sports betting, customized betting, and the like. Forexample, in some embodiments, players may engage in games of chance orin interactive games that require at least one player decision after thegame has begun. The decisions and interactions within the interactivegames can directly affect the outcome of the game. Interactive games caninclude games of skill, games of chance and/or hybrid games that mixgames of chance and games of skill. Examples of interactive gamesinclude, but are not limited to, poker, blackjack, video and arcadegames, virtual reality games, eSports, live dealer, pinball, games ofchance with bonus rounds that include games of skill, and others. Theinteractive games can include head-to-head games where one player orteam of players compete directly against another player or team ofplayers. In some embodiments, the interactive game may be a singleplayer game where the player is trying to meet various objectives (e.g.,score a desired number of points, reach a certain level, complete ascreen within a limited time frame, beat a computerized player, and thelike).

While not illustrated in FIG. 1 , gaming terminals 110A-110D can includea game display area, touch screen interfaces, buttons, joysticks,actuators, biometric sensors, cameras, jackpot payout information areas,player interaction areas, cash and credit interaction areas and/or othercomponents or areas for displaying information or receiving inputs fromplayers 120. For example, a game display area can provide a visualdepiction of the game in which the player is involved. As anotherexample, a jackpot payout information area can display information aboutthe status of jackpot accumulations. The amounts associated with thevarious jackpots may increase with time and may be game specific. Forexample, if the player terminal provides the possibility to engage indifferent types of games and limits, then the jackpot amounts displayedin the jackpot information area may change with different player gameselections.

Some embodiments allow the gaming platforms 110A-110N to utilize adistributed multi-ledger gaming architecture to create a secure ledgersystem for recording money transfer, play action, bets, gamingstatistics (e.g., payouts, skill levels, etc.), code, and the like. Insome embodiments, gaming platforms 110A-110N can directly interact withthe distributed multi-ledger architecture for secure and transparenttransactions which can also be accessed by auditors, tax authorities,partners and/or other entities. Some embodiments may use private and/orpublic blockchains as part of the distributed multi-ledger gamingarchitecture. For example, various transactions or other informationsuch as bets, money transfers, records of game play, digital currency,loyalty information, avatars, game states, jackpot amounts, and othertransactions may be recorded on the blockchain. In some embodiments,executable code may be stored in the ledger that allows the gamingsystem to retrieve the most recent version of the game. The blockchaincan provide a chronological recording of these various transactions orcode in a ledger that can be distributed across multiple nodes thenetwork. As such, these nodes can each keep a copy of the transactionsor code, which is accessed and updated in a decentralized manner.

In some embodiments, the distributed multi-ledger architecture can beused to create, record, and enforce customized bets between multipleparties (e.g., two or more parties). For example, if two parties wouldlike to bet on an event, this bet can be recorded within the ledger. Theparticipants can agree on wager, outcome conditions, validation source,rules, and other conditions or parameters to create a customized bet. Insome embodiments, the ledger may include code snippets that whenexecuted evaluate the outcome and automatically transfer money as setforth with the conditions of the bet. By writing the wagering amounts,rules, outcomes, verification details, and the like into the ledger(e.g., a block in a blockchain) the bet can be tracked and verified.

FIG. 2 is a block diagram 200 illustrating a distributed multi-ledgergaming architecture that may be used according to embodiments of thepresent technology. In accordance with various embodiments, thedistributed multi-ledger gaming architecture provides a secure ledgersystem for recording money transfer, play action, bets, analytics,gaming statistics (e.g., payouts, skill levels, etc.), and the like. Insome embodiments, servers can retrieve and store information in adistributed ledger that is duplicated multiple times at different nodes.

The gaming architecture illustrated in FIG. 2 can allow for a variety ofgaming activity including, customized betting using smart contracts,peer to peer play, skill-based games, augmented reality games and/orbetting, virtual reality games, traditional casino games, arcade games,video games, and others. Peer to Peer and Skill-based games allow usersto compete against each other for money either in a direct one on onemanner or in a non-direct multiplayer tournament environment. This styleof gaming differs from traditional gambling in that the results aresomewhat determined by the actions of each player relative to theactions of the other player(s). The results are not 100% predeterminedby a computer or randomly generated from slot machine. In a traditionalcasino game, either the player wins or the casino wins. Some embodimentsof the gaming architecture the casino can take a rake or processing feefor each game.

Various embodiments of the gaming architecture provide for an open,scalable, and flexible Peer to Peer/Skill-based gaming platform thatallows for wagering (e.g., real money, virtual currencies, etc.). Insome embodiments, the system may limit certain types of game play solegal gaming jurisdictions like Nevada, Indian reservations andinternational markets.

Some embodiments use a peer to peer matching engine to provide a simpleand intuitive interface for finding, negotiating with, and playingagainst other players. This functionally can be self-contained andaccessible via an API that will allow for the production of custom builtend-user interfaces to utilize currently deployed equipment on thecasino floor, wireless handheld devices, kiosks, tablets, computers,gaming cabinets, set-top boxes, interactive and smart TVs, and otherclient devices. The interfaces can be easily customized for visualconsistency with existing framework. The platform can also bedynamically adjusted for localization requirements such as language,currency, and local rules.

Some embodiments allow an individual player the ability to challengeanother individual player in a heads up 1-on-1 (Peer to Peer) matchwhere the competitive environment could include games. The games couldbe anything from Poker to War to Chess to Madden Football. The playerscan negotiate with each other, through some embodiments of the platform,on how much money to play for, before the players actually play thegame. Once the agreed upon wager has been determined, each playersaccount is debited the agreed upon wager, or cash money is depositedinto the machine “Cash In” device as the form of payment for the match.The players play the game and once the game is over and a winner hasbeen determined, the winners account is credited with the wagered amountminus the house transaction/processing fee. Additionally, the playerscould receive a “Ticket Out” coupon for their remaining balance that canbe turned in for cash. These two players can have a rematch or return tothe lobby of this game, on our platform, to find another player tochallenge in either the same game or choose a different game.

An alternative method for providing a heads up 1-on-1 (Peer to Peer)match would be for a player to predetermine and specify his/her “Match”conditions. These conditions could be posted for other players to viewand accept if agreeable. Additionally, the posting player could specifythat they are agreeable to modifications of their conditions. Thismethod while still allowing for customized conditions of matches alsoprovides a quicker path to a match than the fully negotiated process.With tournaments, various embodiments of the system can allow theplayers to play the game, but not necessarily in a heads up 1-on-1 (Peerto Peer) fashion, but as a single player trying to get the best scorepossible. Tournament style of play allows the players the ability tocome to play the games without having to challenge other players to amatch and negotiate a fee. Tournament style of play additionally allowfor an added dynamic of a “Many vs. Many” environment, which providesmany additional options for payouts and Tournament types.

The clients illustrated in FIG. 2 , may include hardware modes thatreduce or simplify network communication, animations, sounds and graphicdetail to provide smooth interaction in any computing environment. Someembodiments provide for a thin client that is designed to maintainminimal logic in the client. Precise visual and functional control ofthe user interface in real-time is possible without ever needing toredistribute or reinstall client software. From changing fonts, colorsand button functions to adding new games, almost any element of theclient experience can be managed instantly from the server. Colors,fonts, background images and even sounds within the client can becustomized for (or by) an operator, a given machine or bank of machines,location of a mobile device, etc.

FIG. 3 illustrates various components of a gaming platform utilizing adistributed multi-ledger architecture according to various embodimentsof the present technology. As illustrated in FIG. 3 , the gamingplatform may use one or more gaming servers 305A-305N. Each gamingserver can include blockchain interface 310, monitoring mechanism 315,gaming interface 320, rules engine 325, encryption/decryption module330, analytics module 335, event module 340, promotion module 345,multifactor authentication module 350, report generator 355, and/ordatabases 360 and/or 365 for storing logs, subscriber policies, gamingpolicies, location policies, and/or the like. In addition, gamingservers 305A-205N can connect with blockchain 370, gaming clients 375,trusted data sources 380, and/or records 385. Each of these modules,components, or databases can be embodied as special-purpose hardware(e.g., one or more ASICS, PLDs, FPGAs, or the like), or as programmablecircuitry (e.g., one or more microprocessors, microcontrollers, or thelike) appropriately programmed with software and/or firmware, or as acombination of special purpose hardware and programmable circuitry.Other embodiments of the present technology may include some, all, ornone of these modules and components along with other modules,applications, databases, and/or components. Still yet, some embodimentsmay incorporate two or more of these modules and components into asingle module and/or associate a portion of the functionality of one ormore of these modules with a different module. For example, in oneembodiment, rules engine 325 and event module 340 can be combined into asingle module for identifying and enforcing various rules and eventpolicies on a player terminal.

Gaming clients 375 may connect to a gaming server 305A-305N using gaminginterface 320. Gaming clients may be able to download (or havepreinstalled) firmware or software from the gaming server that allowsthe gaming clients to play one or more games. Types of games that may beaccessed through a gaming interface (e.g., gaming interface 320)comprise but are not limited to: role playing games (RPGs); real-timestrategy (RTS) games; multi-player online games (including massivemultiplayer online games); battle royale games; first person shootergames; browser games; player versus player games; player versusenvironment games; games of skill; and games of chance, among othertypes of games. Non-limiting examples of such games may comprise avariety of games (e.g., Texas Hold'em, 7-Card Stud, Omaha, Draw poker,2-7 lowball, Blackjack, Bridge, pinball, Grand Theft Auto, Tetris,Minecraft, Hearthstone, Super Mario, Super Mario Kart, Pac-Man, GuitarHero, Galaga, League of Legends, Frogger, StarCraft, Donkey Kong, wordswith friends, Sonic the Hedgehog, Counter-Strike, Metroid, Ms. Pac-Man,Space Invaders, Punch-Out, Rainbow Six Siege, Fallout, Final Fantasy,Call of Duty, Street Fighter, Dota, Journey, Dark Souls, role playinggames, decision based games, etc.) and a variety of limits ($0.25/$0.50,$11$2, $11$2 Blind No Limit, $10/$20, $500/$1000, etc.).

In some embodiments, the players may be able to select the game playedin the gaming session and a game of skill to be played in the bonusround. The game session may be a tournament, which may be a single-tabletournament or a multi-table tournament. The games may allow forpeer-to-peer play or allow for customized betting on external events(e.g., sports, weather, elections, etc.).

In some embodiments the games may also include augmented reality gamesand/or virtual reality games. Transactional data related to wagers maybe stored in block chain ledgers. Examples of wagers comprise but arenot limited to: unique prizes, game-specific points, currency (physicaland digital), virtual goods and digital goods, rewards, clues, points,power-ups, videos, character modifications, recordings, or othercollectibles, data, among other examples. Pending transactional data,digital wallets, funds, wagers, etc., may be accessible through a playeraccount associated with a gaming platform. In other examples,transaction data may be accessible through a player terminal when theplayer terminal is at a particular physical location and/or when certainconditions are met (e.g., the player completes a certain task). As such,blockchain 370 may track how many times they have been accessed and thendeny or restrict future access or change the access criteria (e.g.,randomly associating the record access with a new location, time, event,etc.). The distributed ledger can be used to keep track of locations aplayer has visited or records of which players have visited a specificlocation (e.g., a geo-located area). As a result, elements of a virtualworld, visits, access, and other information can be tracked on anauditable trail on the distributed ledger (e.g., block chain 370). Insome embodiments, a third-party repository may payout prized or betsidentified within a private blockchain.

The software may require a connection to a gaming server (e.g., usinggaming interface 320) each time a game is played or a connection withina specific time period (e.g., one week). In some embodiments, the gamingserver may manage or host the game. In other embodiments, gaming clients375 may run the games independently and report activity back to a gamingserver. The gaming client can record various activity (e.g., bets,gaming action, user inputs, etc.) which can be stored on a distributedmulti-ledger platform such as block chain 370. Blockchain 370 may be aprivate, public, hybrid, and/or semi-private platform that can beaccessed by gaming servers 305 via blockchain interface 310. A hybridblockchain runs on the open internet and is accessible to anyone like apublic blockchain, but the hybrid blockchain uses a smaller set ofvalidators and is more targeted towards a specific use case like aprivate blockchain. The information stored in blockchain 370 may beencrypted using encryption/decryption module 330.

In some embodiments, encryption/decryption module 330 may use variousnonhomomorphic encryption and/or homomorphic encryption. While thenonhomomorphic encryption may provide stronger security properties, theuse of homomorphic encryption would allow computation on encoded datawithout decryption. As a result, various components of the gaming systemcan interact and operate on portions of the data without exposure ofsensitive data. Other embodiments may use multiple levels ofauthentication and trust to either retrieve or add data to the system.For example, gaming terminals within a casino that are under a strictercontrol may have a greater trust level and have the ability to addand/or retrieve more from blockchain 370. Similarly, remote gamingterminals (e.g., user devices) may have a lower trust level thatrequires additional authentications (e.g., operating systemverifications, application verifications, user verifications, and thelike) before information can be added to or retrieved from theblockchain.

Certain information may be available to all users, while otherinformation may have higher trust or verification requirements. In someembodiments, individuals, machines, third-parties, etc. can havedifferent access levels. For example, an auditor may be allowed to viewall player information, casino information (e.g., profits, employeeinformation), know-your-customer (KYC) information,anti-money-laundering (AML) information, tax information, and the like.As another example, a manager of a casino, an executive team, higherlevel management, or certain regulators or auditors that are overseeinga player may be granted access to KYC and AML information, but not otherinformation stored on the multi-ledger system. A person responsibleconducting a tournament, for example, will not be able to see thisinformation and may instead on get summary or aggregated informationregarding the tournament (e.g., number of players, jackpot amount,etc.). Tournament players, for example, may only be able to see picturesor confirmation of matches of a biometric data. Similarly, other playersmay only be able to see advertised play rates that are retrieved fromthe ledger.

In some embodiments, they system may include a master blockchain thatrecords all of the available information. Portions of the informationmay be combined or duplicated to additional blockchains that allowaccess to different third-parties. For example, some embodiments mayscrub personal identifying information and publish certain information(e.g., game payout rates) that are accessible to anyone while a secondblockchain that is private may include not only game payout rates, butthe raw underlying data that is needed by a regulator to validate thepayout rates. Some embodiments may partition the blockchain intodifferent segments that allow access (e.g., read and/or write) based ondiffering privileges and/or trust levels (e.g., different levels forIRS, pit boss, etc.).

Some embodiments allow data to be shared between auditors, casinos,banks, and the like. The specific type of information to be shared canbe customized and set using various permissions and access controllayers. For example, party information, escrow data, deal data, and thelike can be shared on a hybrid ledger, but may not be visible on theprivate ledger (e.g., block chain). Regulators and auditors can see thefull transaction details to make sure they are legally compliant andreporting properly. Part of the information could be on publicblockchain to allow players to see published payout rate and feel likethey are being treated fairly. Payouts may be visible on the publicblockchain without any personal identifying information. This data couldbe retrieved and viewed by various systems or players. Some embodimentsmay use cashless wagering. Amount of money or value on account or cardwould be on the private blockchain along with and biometric/password/pinand bank account, balance, etc. Some other info (e.g., nickname) may beon a public blockchain. A reservation does not need access to creditcard on private blockchain to make the reservation, but instead uses thepublic blockchain information and then credit card data can be accessedfor payment from the private blockchain to pay for dinner. Monitoringmechanism 315 can monitor game play and player activities. This caninclude receiving information from external sources such as, but notlimited to, gaming clients 375, video surveillance systems, loyalty cardsystems, key engines, biometric sensors, and other external systems. Forexample, in some embodiments, monitoring mechanism 315 can collectinformation regarding use of hotel room keys and/or loyalty cards todetermine movement patterns within the casino. This informationcollected, aggregated, and/or analyzed to look for collusion, cheating,gaming preferences, gaming patterns, and the like.

In some embodiments, multifactor authentication may be used beforeallowing a player to access a game, access or transfer funds, and/orplace bets. For example, when a player accesses a gaming terminal anddesires to enter a wager, multifactor authentication module 350 may beused to require various types of authentications (e.g., personal pin,password, biometric, audio and/or video associated with a user, token,public/private keys, etc.). This type of data may be further used duringconsensus evaluation to verify transactions (e.g., wagers) formodification of a blockchain ledger and/or access to player accounts(e.g., physical goods, virtual goods, characters). Rules engine 325 cansuperimpose rules on the games or betting interfaces being presented ongaming clients 375. These rules can be based various policies (e.g.,subscriber policies, gambling policies, location policies, etc.) storedin database 365. Analytics module 335 can generate various analyticsabout layers, gaming clients, games, payouts, accounts, and/or othersystem components or activity. This information can be used by reportgenerator 355 to create customized reports.

Event module 340 can be used to create customized rewards for players.The rewards may be stored within blockchain 370 in records 385. Thegames may be able to access these records (e.g., of the player, day,time, location, etc.) and present customized rewards or betting based onthose records. Promotion module 345 can present customized promotionsfrom the casino, nearby restaurants, shows, or other companies and/orproducts. Databases 360 and/or 365 can be used for storing logs,subscriber policies, gaming policies, location policies, access torecords, retrieval of and/or the like. These may be local stores of dataretrieved from records 385 associated with blockchain 370. In addition,gaming servers 305A-305N and blockchain 370 can connect with trusteddata sources 380 for validation of external events (e.g., outcome ofsporting events, etc.) that are needed to determine a winner of acustomized bet stored within records 385.

FIG. 4 illustrates various components of an example gaming platformutilizing a distributed multi-ledger architecture according to variousembodiments of the present technology. As illustrated in FIG. 4 , thegaming platform may include a virtual goods (VG) platform 410, one ormore gaming servers 405, a blockchain 470, one or more third-party VGsponsors 425 and one or more eSport VG spectators 435. The gamingservers and gaming clients can be, for example, gaming servers 305A-305Nand gaming clients 375 of FIG. 3 , although alternative configurationsare possible.

The gaming clients may connect to the gaming servers using a gaminginterface. Likewise, the gaming clients may be able to download (or havepreinstalled) firmware or software from the gaming server that allowsthe gaming clients to play one or more games that can include virtualgoods (or items). The virtual goods may be any non-physical virtualobjects (or currency) that can be used within a game. The virtual goodsmay be purchased, traded, or otherwise obtained within the game itselfor externally from the game, e.g., via third-party marketplace orvirtual goods wallet software. For example, crates or containerscontaining one or more virtual goods can be placed within the game andfound by players, traded between players within the game or external ofthe game, gifted to another player, temporarily shared with a teammate,or offered externally to players as promotions or for purchase by theplayers via virtual or non-virtual currency. Additionally, a third-partymarketplace can facilitate external virtual good transactions, or avirtual goods wallet software can be downloaded and utilized to tradevirtual goods between players external to the game utilizing blockchain470 for verification and security.

In some embodiments, the virtual goods may include player (character) orweapons (item) “skins.” The “skins” may include cosmetic elements thathave no direct influence on gameplay or, alternatively, can affect orotherwise enhance the abilities of a character or item. For example, aplayer skin can provide a character with invisibility within the game orenhance a weapon or armor. Alternatively, the “skin” may simply providea different look or feel to the player or weapon. In some embodiments,the player “skins” may also include a collection of virtual goods. Thecollection may include both cosmetic elements and non-cosmetic elementsor enhancements, e.g., particular weapons, etc. For example, inaccordance with various embodiments, skins can include paint jobs,cosmetics, articles of clothing (e.g., hats, jackets, boots, gloves,pants, shirts, backpacks, etc.), digital items, virtual items, cryptocollectables, non-fungible tokens (NFTs), and the like.

In some embodiments, the virtual goods (including “skins”) can be usedas virtual currency both within and external to the game. Additionally,the virtual goods can have different properties over time, e.g.,expiration dates, effectiveness intervals, etc. For example, a specialherb that is going to grow in a virtual forest within the game may take30 days to become ripe. If a character finds the herb too soon and picksit too early, then the properties of the herb and/or effectiveness canvary, e.g., initially poisonous then partially beneficially and, oncefully ripe, the herb can provide valuable enhancements to a character oritem. Accordingly, tracking the attributes, e.g., ownership, status andfeatures, etc., of the virtual goods including “skins” is extremelyimportant. Tracking these changes via blockchain 470 ensures thevalidity of transactions and virtual goods and provides various levelsof security.

In some embodiments, the virtual goods that belong to a character orplayer can be maintained externally in a wallet or inventory associatedwith the character or player. The gaming servers can alternatively oradditional maintain this information. In either case, the blockchain 470is accessed to verify ownership, status, etc., prior to access, use ortransfer of a virtual good.

As discussed herein, virtual goods can be traded both within the gameitself or externally from the game. The VG platform 410 may connect tothe gaming server 405, the gaming clients 475, the blockchain 470, thethird-party VG sponsors 425 and the eSport VG spectators to facilitatetracking of the virtual goods within a game using the blockchain 470. Asshown in the example of FIG. 4 , the VG platform 410 executes a VGtracking service to facilitate tracking of virtual goods within the gameusing the blockchain 470. As discussed herein, tracking the virtualgoods can include tracking one or more components or attributes of eachvirtual good, e.g., ownership, expiration, special features, status,etc. Some or all of the components and/or functionality discussed withrespect to VG platform 410 may be middleware (software) and canalternatively or additionally be included on or within the one or moregaming servers 405.

In some embodiments, the third-party VG sponsors can interact with theVG platform 410 and, more particularly, the VG tracking service 411 tofacilitate control and/or management of the number of containerspresented within the game and the contents of those containers. Forexample, a third-party VG sponsor may want to distribute a limitednumber of “skins” over a period of time. The VG platform 410 may receiveand handle the request to ensure that the appropriate containers and/orcontents of containers are distributed over a requested period. Variousadditional example illustrating control of the distribution of virtualgoods using the blockchain 470 are shown and discussed in greater detailwith reference to FIG. 5 .

Although not shown, in some embodiments, the third-party VG sponsors caninteract directly with the blockchain 470 to directly control (e.g., setconditions for) the distribution of containers presented within a gameand the contents of those containers using the blockchain 470. In suchinstances, a software API or enhanced interface to the blockchain 470can be provided and downloaded by the third-party VG sponsors. Theblockchain 470 can then receive and execute the distribution code whenrequested to do so by a gaming server to determine contents ofcontainers within the game. In some embodiments, the request can beinitiated at startup, e.g., when a game loads, periodically, each timethat a virtual good is accessed within the game, or at some otherinterval, including combinations or variations thereof.

In some embodiments, eSport VG spectators can interact directly with theblockchain 470 and/or gaming servers 405 to purchase virtual goods forcharacters in a game thereby potentially influencing the outcome ofgames. These purchases can be made in real-time to potentially influencethe outcome of a game.

FIG. 5 illustrates an example 500 of gaming client(s) 505 and/or thegaming server(s) 525 interacting directly with the blockchain 550 toverify or otherwise obtain attributes of a virtual good 575 during thecourse of a game according to various embodiments of the presenttechnology. For example, as discussed above, gaming clients 505 mayinteract with a virtual good 575 during the course of a game. Theinteraction can include various actions including, among others,attempting to use a virtual good 575, obtain a newfound virtual good,purchase a virtual good from an in-game marketplace, etc. In each ofthese scenarios, the gaming server(s) 525 may attempt verify theexistence of the virtual good 575 in real-time as well as otherattributes of the virtual good, e.g., ownership. In someimplementations, the virtual good 575 may contain a direct link orreference to the blockchain (or the distributed ledger).

Additionally, in some embodiments, the gaming server(s) 525 can generaterequests to create new virtual objects in response to a player'sactions. For example, two virtual objects can be combined, merged, orotherwise morphed into a new virtual object. For example, two uniquevirtual objects may be combined to form an even more unique (orvaluable) virtual good. In such an instance, the gaming server(s) 525can generate a transaction request that would add a new block to theblockchain 550 indicating the creation of the new virtual object anddestruction of the merged (or combined) virtual objects. In this manner,the blockchain 550 acts as a recording mechanism of the virtual goodswithin one or more games. The virtual good 575 may or may not have anymonetary value or value on an exchange hosted outside of the gamingplatform. For example, the virtual good 575 may be developed and givenby an advertiser.

FIG. 6 illustrates various components of an example gaming platform 600utilizing a distributed multi-ledger architecture to manage virtualgoods according to various embodiments of the present technology. Asillustrated in FIG. 6 , the gaming platform 600 may include a virtualgoods (VG) platform 610, one or more gaming server(s) 625, one or moregaming clients 650 a blockchain 670 and one or more third-party VGsponsors 680. The gaming server(s) 625 and gaming client(s) 650 can be,for example, gaming servers 305A-305N and gaming clients 375 of FIG. 3 ,although alternative configurations are possible.

As discussed above, the third-party VG sponsors 680 can interact withthe VG platform 610 to facilitate control and/or management of thenumber of containers presented within a game on the gaming server 625and the contents of those containers. For example, a third-party VGsponsor 680 may want to distribute a limited number of virtual goodsover a designated period of time and initiate a request to the VGplatform 610 that identifies the one or more virtual goods and variousvirtual good distribution parameters for distributing those virtualgoods within the game and/or external to the game. In some embodiments,the VG platform 610 receives and handles the request to ensure theappropriate containers and/or contents of containers are distributed inaccordance with the virtual good distribution parameters. The virtualgood distribution parameters can include, but are not limited to, thedesignated time period, the preferred method of distribution, e.g.,crates, randomness of the distribution, percentage or limited number ofvirtual goods (e.g., 1000), limited editions, lifespans, capabilities,etc. As an example, a virtual good container 690 (or virtual good crate)may be created for a specific type of virtual goods or for virtual goodsprovided by a specific third-party VG sponsor 680. The virtual goodcontainer 690 may comprise data and/or metadata associated with creationand management of virtual good containers including but not limited to:manifests, attributes, ownership, sponsors, statuses, special features;timestamp data; and duration data (e.g., where virtual goods are offeredfor a limited time period), among other examples. The virtual goodcontainer 690 may be associated with one or more virtual goods, forexample, virtual good 691 and virtual good 692. In some examples,virtual goods may be rolled out in waves, where the virtual goodcontainer 690 may be continuously updated (e.g., adding, removing,re-organizing virtual goods).

In some embodiments, the third-party VG sponsors 680 subscribe to asubscription service provided by the VG platform 610 to distribute thevirtual goods in accordance with the virtual good distributionparameters. Although not shown, the VG platform 610 can provide an APIor graphical user interface for obtaining the third-party VG sponsors680 subscription information. As discussed above, the VG platform 610provides the blockchain 670 with one or more transaction requests toimplement the subscription. The VG platform 610 may further enableinterfacing with the third-party VG sponsors 680, where the third-partyVG sponsors 680 can provide messaging and notifications through thegraphical user interface of a gaming platform, for example, related tomanagement of virtual good container(s) 690 and associated virtual goods(e.g., virtual goods 691 and 692).

FIG. 7 illustrates an example of various components of a gaming client700 according to one or more embodiments of the present technology. Asshown in FIG. 7 , gaming client 700 may include memory 702 (e.g.,volatile memory and/or nonvolatile memory), processor(s) 704, powersupply 706 (e.g., battery), for executing processing instructions, andoperating system 708. In one example, a gaming client 700 may be acollection of components in a stand-alone computing device such asterminal 110 (FIG. 1 ). In other examples, gaming client 700 may be aconfiguration of components operating as a gaming console (e.g., clientgaming system), which may be utilized to access a gamingapplication/service over a network connection. In yet another example agaming client 700 may interface with a client computing device such as acomputer, tablet, smart phone, etc., whereby the client computing devicemay be adapted for execution of a gaming application/service so thatprocessing operations described herein may be executed. In alternateexamples, components of a gaming client 700 may interface in adistributed configuration, where components are connected over a networkconnection.

Additional components of gaming client 700 may include data storagecomponent 710 (e.g., hard drive, flash memory, memory card, etc.), oneor more network interfaces (e.g., Bluetooth® Interface 712; and NetworkCommunication Interface 714, which enables the player terminal tocommunicate by transmitting and receiving wireless signals usinglicensed, semi-licensed or unlicensed spectrums over atelecommunications network), audio interface 716, microphone 718,display 720, keypad or keyboard 722, SIM card 724, other input and/oroutput interfaces 726, biometric interface 728 (e.g., fingerprintreader, facial recognition module, etc.), payment system 730, and gamingmodule 732. The various components may be interconnected via a bus.

Memory 702 can be any device, mechanism, or populated data structureused for storing information. In accordance with some embodiments of thepresent technology, memory 702 can encompass any type of, but is notlimited to, volatile memory, nonvolatile memory and dynamic memory. Forexample, memory 702 can be random access memory, memory storage devices,optical memory devices, media magnetic media, floppy disks, magnetictapes, hard drives, SDRAM, RDRAM, DDR RAM, erasable programmableread-only memories (EPROMs), electrically erasable programmableread-only memories (EEPROMs), compact disks, DVDs, and/or the like. Inaccordance with some embodiments, memory 702 may include one or moredisk drives, flash drives, one or more databases, one or more tables,one or more files, local cache memories, processor cache memories,relational databases, flat databases, and/or the like. In addition,those of ordinary skill in the art will appreciate many additionaldevices and techniques for storing information which can be used asmemory 702.

Memory 702 may be used to store instructions for running one or moreapplications or modules on processor(s) 704. For example, memory 702could be used in one or more embodiments to house all or some of theinstructions needed to execute the functionality of the various systemcomponents and/or modules. Processor(s) 704 are the main processors ofplayer terminal 110 which may include application processors, basebandprocessors, various coprocessors, and other dedicated processors foroperating player terminal 110. For example, an application processor canprovide the processing power to support software applications, memorymanagement, graphics processing, and multimedia. An applicationprocessor may be communicably coupled with memory 702 and configured torun the operating system 708, the user interface, and the applicationsstored on memory 702 or data storage component 710. A baseband processormay be configured to perform signal processing and implement/managereal-time radio transmission operations of a player terminal (e.g., amobile device). These processors, along with the other components, maybe powered by power supply 706. The volatile and nonvolatile memoriesfound in various embodiments may include storage media for storinginformation such as processor-readable instructions, data structures,program modules, or other data. Some examples of information that may bestored include basic input/output systems (BIOS), operating systems, andapplications.

Operating system 708 can also provide common services for softwareapplications running on processor(s) 704. According to the embodimentsshown in FIG. 7 , gaming module 732 can include identification module734, policy enforcement module 736, blockchain interface 738, bettingengine 740, custom bet module 742, and/or betting wallet 744. Each ofthese modules can be embodied as special-purpose hardware (e.g., one ormore ASICS, PLDs, FPGAs, or the like), or as programmable circuitry(e.g., one or more microprocessors, microcontrollers, or the like)appropriately programmed with software and/or firmware, or as acombination of special purpose hardware and programmable circuitry.Other embodiments of the present technology may include some, all, ornone of these modules and components along with other modules,applications, and/or components. Still yet, some embodiments mayincorporate two or more of these modules and components into a singlemodule and/or associate a portion of the functionality of one or more ofthese modules with a different module.

For example, in one embodiment, identification module 734 and policyenforcement module 736 can be combined into a single module foridentifying and enforcing various policies on a player terminal. Asanother example, some embodiments may include additional modules orcomponents not illustrated in FIG. 7 such as, but not limited to, askill level adjustment module, payout adjustment module (e.g., todynamically adjust payment of a particular machine or game based onhistorical payouts, player skill level or other factors), accountingmodule (e.g., to interface with various existing backend accountingsystems and other reporting and record keeping systems, such as an IRSreporting systems), and/or a state recordation module (e.g., to capturethe state of a gaming activity such as, but not limited to, wager,payout levels, skill level settings, user interactions, and othersactivity).

Identification module 734 can be used to gather information about theplayer terminal, current and/or past gaming sessions, playerinformation, specific hardware and software configurations of the playerterminal, GPS coordinates, associated telephone numbers, IP addresses,e-mail addresses, user identifiers, international mobile stationequipment identity (IMEI), mobile equipment identifiers (MEID),integrated circuit card identifiers (ICCID), part identifiers, softwareidentifiers, current gaming session identifiers, identification of anynearby player terminals, and the like. In some embodiments, thisinformation can be stored within the blockchain as a way of trackinguser activity. In some embodiments, this information can be used bypolicy enforcement module 736 which can set customized collusionavoidance policies from that can, in some embodiments, be dynamicallyset (e.g., based on location, current gaming session, etc.). In someembodiments, policy enforcement module 736 can retrieve policies from ablockchain using blockchain interface 738 or from a database associatedwith a gaming server using network communication module 714.

In accordance with various embodiments, gaming module 732 can alsoinclude a betting engine 740 that allows the player to place bets.Betting engine 740 can restrict gambling in certain locations, ensurethat requirements are met for placing bets, and/or other functions. Insome embodiments, betting engine 740 may use custom bet module 742 tocreate customized bets between two or more players or between a playerand the house. For example, custom bet module 742 could present agraphical user interface that allows users to create customized betswith specific betting amounts, conditions, validation sources, and thelike. In one instance, the graphical user interface may be adapted toenable user to select a wager type (e.g., whether the wager is forcurrency, goods, barter, services, etc.) and/or wager amount. Forinstance, a user may elect to make a bet in a casino style game, bet onan occurrence of an event (or series of events) or individually definethe terms associated with the bet. A user may initiate a customized beton anything under the sun. In one example, a user may make a bet withhis friend as to whether it will rain in a specific location on a givenday.

Further, the graphical user interface may be adapted to enable users toset specific conditions or parameters associated with a bet.Non-limiting examples of conditions and parameters comprise but are notlimited to: duration; user-defined conditions such as terms andrestrictions for defining the scope of the bet; triggering events fordetermining an outcome of a bet; number of bets to be considered for adetermined outcome; and associated physical, virtual and/or digitalproperty associated with the bet such as player characters, attributes,rewards, virtual goods, etc., among other examples. Betting wallet 744can keep track of individual games played and bets made by a player.Betting wallet 744 may be associated with an individual user/playeraccount or an account associated with a group of users/players. In someembodiments, collusion detection may be running during game play or uponcompletion of the gameplay before any winnings are paid out. The usercan also customize the bet to define a validation source for validationof the outcome of a bet. In some cases, multiple validation sources maybe utilized to confirm an outcome of a bet, where the user can definespecific validation sources that they prefer to use or select to allowthe gaming application/service to utilize its rule engine toautomatically determine how to validate an outcome.

FIGS. 8A-8C illustrates example sets of operations (e.g., methods) forutilization of a distributed multi-ledger architecture for themanagement of gaming activity in accordance with some embodiments of thepresent technology.

As illustrated in FIG. 8A, a player may register with a gaming platform,implementing a gaming application/service, using registration operation802. In some embodiments, registration operation 802 may includepresentation of a graphical user interface to collect information aboutthe player. In other embodiments, the registration may allow the user toremain anonymous by issuing a private/public key pairing for which thepublic key is used by the gaming platform as a way tracking bets andgaming activity. As such, a player may desire to use one or moreprivate/public key pairs for gambling activity on the system. Playerregistration with a gaming platform (operation 802) may comprise a userregistering a user account with the gaming platform. Some users may beaffiliated with multiple user accounts or a group account. A player mayutilize their user account to execute bets for gameplay, bets withcustomized parameters and/or bets with one or more other users.

Using funding operation 804, a player can associate funds with theprivate/public key pairing created as part of the registration process.Entry operation 806 can then create an entry in the distributedmulti-ledger system (e.g., blockchain) that associates the fund with theplayer. Using initiation operation 808, a player can initiate a gamefrom a gaming client within initiation operation 808 and recordationoperation 810 can create a record of the gaming activity to be stored inthe multi-ledger system (e.g., blockchain). Creation of record 810 maycomprise storing data, received through a graphical user interface of agaming application/service, that is associated with the bet. Such datamay include customized data as entered by the player including theselection of specific data fields of to customize the bet as well aspossible entry of data fields that are customized by the user. Forinstance, the graphical user interface may be configured to enable aplayer to select a wager type field, a condition field, a parameterfield and/or a validation source field, where the player can openlydefine the terms of the wager through its user input. Such data may beincluded in a block record of a blockchain. In some instances, a hashvalue for block may be determined from wager-specific data fields orother data fields (e.g., conditions, triggering event, validationsources) that are associated with the customized bet. A hash may furthercomplete previous blocks, of a blockchain ledger, where creation(operation 810) of a record may associate a transaction for a customizedbet with one or more other transactions as well as create a block ablock for the transaction(s) from a previously created block of theblockchain ledger.

The record, created in operation 810, may further store other types ofsignal data associated with the customized bet including but not limitedto: device signal data, application/service signal data and user-signaldata, which may be further used to provide context associated with acustomized bet. For instance, device signal data may be collected thatindicates a GPS location or IP address associated with a player/useraccount that is making the customized bet or accepting terms of acustomized bet initiated by another player. In other examples, biometricdata, video or audio data may be collected, e.g., through the usercomputing device or peripheral devices in a location of the user, at thetime where a betting transaction is being created or confirmed. Suchdata may be utilized to validate that a specific user is authorizing thecustomized bet as well as utilized in a consensus determination, bynodes, to validate a block of a blockchain ledger. In other instances,signal data associated with a user account, such as security questions,PIN numbers, etc., may be further utilized to validate or authenticate atransaction made by a player. Any signal data collected may be done soabiding with privacy regulations and with user consent.

The player terminal can broadcast the record to various gaming nodes forvalidations during broadcast operation 812. Broadcasting (operation 812)of the record may make the record available for validation, where gamingnodes may execute a determination as to whether the block, thatcomprises the transaction record for the customized bet, should be addedto the blockchain ledger. Gaming nodes may be associated with a gamingplatform, that executes a gaming application/service, where the gamingnodes connect to the gaming platform via network connection.Broadcasting (operation 812) of the record may further comprisesrandomly selecting a group of nodes to validate a created block foraddition to the ledger. This may occur through execution of codeassociated with a blockchain protocol for the gaming platform. In somecases, gaming nodes may ping the gaming platform to indicateavailability for validation of a block for addition to the ledger. Ablockchain protocol, associated with the gaming platform, may select aplurality of gaming nodes to validate a block. In some instance, theblockchain protocol may call for selection of a group of gaming nodes,where an additional level of curation is executed on the selected groupto determine a subset of multiple nodes to actually execute validationof a created block. This may help to ensure randomness in blockvalidation and deter potentially fraudulent activity.

Flow of the set of operations may proceed to operation 814, where it isdetermined whether a consensus has been reached by the gaming nodes foradding the block to the ledger of the gaming platform. As indicated inthe foregoing description, a blockchain protocol may be implemented tovalidate addition of a transaction to a distributed ledger (e.g.,blockchain ledger) in a decentralized manner. As identified in theforegoing, a grouping of gaming nodes may be used to validation theblock for addition to the ledger. The blockchain protocol may beimplemented to request that the created record be validated via aconsensus decision of the subset of the gaming nodes. A consensusdetermination is an agreement amongst a majority of gaming nodes (e.g.,nodes that are selected for validation of the block), where at least amajority of the gaming nodes must agree that the block is valid foraddition to the ledger of the gaming platform. A consensus determinationis configured to ensure that blockchain ledgers are evaluated in adecentralized manner. The number of nodes that need to agree, for aconsensus agreement, may be set by developers and defined through theblockchain protocol. In one instance, at least six (6) of the gamingnodes may be required to agree that a block is valid for addition to aledger in order for a consensus to be reached. However, any number ofnodes may be set for a consensus decision without departing from thespirit of the present disclosure.

A subset of the gaming nodes may be configured to individually executescode to reach the consensus decision. Consensus decisions may be reachedthrough implementation of a proof algorithm. Non-limiting examples ofproof algorithms, executed by the gaming nodes, may comprise but are notlimited to: proof of work (PoW) algorithms; proof of stake (PoS)algorithms; delegated PoS algorithms; proof of importance (PoI)algorithms; proof of activity (Poa) algorithms multi-signature/byzantinefault tolerance (BFT) algorithms; customized algorithms configured tovalidate data associated with transactions of the gaming platform (e.g.,bets) and/or player account data, and any combination thereof. In oneexample, the consensus determination comprises validation of acryptographic hash, associated with creation of the customized bet, bythe subset of the multiple nodes. In one example, a hash of createdblock may be validated and/or hashes associated with previously createdblocks. In another example, the consensus decision may comprisevalidation of a cryptographic puzzle associated with cryptographic hash.Difficulty in solving cryptographic puzzles may vary based on the amountof transactions (e.g., bets, fund transfers, etc.) being executed andthe speed at which blocks are validated for addition to a ledger.

In further examples, the consensus decision comprises confirmation thatthe record of the customized bet has not already been added to thegaming platform (e.g., distributed multi-ledger platform). This may helpto avoid having duplicates of a bet and/or fund transfer that maynegatively affect operation of a gaming application/service. Inadditional examples, the consensus decision comprises validation of oneor more of: biometric authentication of the player, authentication ofimage data associated with the player; authentication of video dataassociated with the player and authentication of audio data associatedwith the player. This may provide further measures of validation toconfirm that a bet was validly made. Validation of additional measuresmay occur in addition to a cryptographic hash evaluation for a createdblock.

In examples where a consensus is achieved amongst the gaming nodesutilized for block validation, flow of the set of operations 800 mayproceed to operation 818 where a record is added to the blockchainledger. The record can include a variety of gaming and terminalcharacteristics (e.g., terminal ID, gaming version number, etc.) alongwith betting amounts, images, videos, biometric validations, snapshotsor records of the game, data or links to data from external sources(e.g., surveillance systems, loyalty tracking information, etc.). Therecorded block may used as a basis to add subsequent blocks to theledger as well as for reference to validate transfer of funds based on adetermined outcome of a bet.

When determination operation 814 determines that a consensus has notbeen reached, then determination operation 814 branches to requestoperation 816, that requests access to local storage and rebroadcastingof the record. In one example, a request for access and rebroadcastingmay occur after a predetermined time period elapses before record data(e.g., of a block) is re-evaluated for validation. For instance,operation 816 may comprise requesting a locally stored copy of therecord to be rebroadcast for validation. A locally stored copy of therecord may be retrieved from a gaming node that created the block. Insome examples, a rebroadcasting (operation 816) comprises re-propagatingthe record to a new set of gaming nodes for executing a consensusdetermination. In another example, operation 816 comprises re-evaluatingthe block and associated data by the same set of gaming nodes. In yetanother example, operation 816 comprises recreating a new block, where atransaction record is included in a new block that is subsequentlyevaluated (e.g., consensus decision determination; operation 814) foraddition to a ledger.

FIG. 8B illustrates an example set of operations 850 for utilization ofa distributed multi-ledger architecture that may be utilized for wagercreation involving virtual goods. As identified in the foregoingdescription, transactions related to virtual goods may be managed usinga transaction ledger that is associated with a gaming platform. Forinstance, a blockchain protocol may be implemented to manage a securedistributed ledger (e.g., blockchain ledger), where virtual goods may bemanaged on a transactional basis. Non-limiting examples of virtual goodscomprise: characters; badges/icons; gameplay attributes; virtual money;cryptocurrencies; tokens; digital gifts; gameplay levels and add-ons;and prizes, among other examples. Further examples of virtual goodscomprise but are not limited to: a cryptocurrency, a paint job, acosmetic, an article of clothing, a digital attribute, a digital item, avirtual item, a crypto collectable, or a non-fungible token.

The set of operations 850 begins with operation 852, where a customizedwager is received that comprises a virtual good. For instance, a playermay create a customized bet that wagers a virtual good (or virtualgoods). In some examples, a player may wager a part of a virtual good(or a partial virtual good). Consider an example where a leveled-upcharacter is associated with the player's user account and the player iswagering skills/attributes, badges icons, etc., which is just one partof the leveled-up character. In any example, a customized wager may bereceived through a user interface of a gaming application/service. Thegaming application/service may be associated with a gaming platform, forexample, that implements an architecture enabling gambling (e.g., adistributed multi-ledger gambling architecture).

Flow of the set of operations 850 may proceed to operation 854, where arecord is created for the customized wager. Record creation includinggeneration of a block for validation of a blockchain ledger has beendescribed in the foregoing description including the description of FIG.8A. Operation 854 may further comprise broadcasting of a created recordfor validation, where a validated record may be added to a block of ablockchain ledger (e.g., a distributed blockchain ledger). Adetermination to add a new record for the customized wager to ablockchain ledger may be executed (operation 856). Processing operationsrelated to execution of a determination to add a record to a blockchainledger have been described in the foregoing description including thedescription of FIG. 8A.

As an example, the determination (of operation 856) is made by aconsensus decision between a subset of nodes such as selected gamingnodes associated with a gaming applications/service. Flow of the set ofoperations 850 may proceed to determination decision 858, where it isdetermined whether a grouping of a plurality of nodes reaches aconsensus to validate the addition of a block to the blockchain ledger.In instances where a consensus decision indicates that the record is notvalidated, flow of determination decision 858 branches NO and processingproceeds to operation 860. At operation 860, a notification may begenerated and published to indicate that an issue exists with thecustomized wager. As an example, a notification may be provided to oneor more of the gaming nodes, selected for validation, and/or the useraccount associated with the customized wager. In at least one example, arecord may be rebroadcast to a subset of gaming nodes for re-validationafter a predetermine interval of time lapses (e.g., after a notificationhas issued). In some instances, a player may have to re-initiate thecustomized wager, where a new record may be created of a newly receivedwager.

In instances where a consensus decision indicates that the record isvalidated for addition to the blockchain ledger, flow of determinationdecision 858 branches YES and processing proceeds to operation 862. Atoperation 862, a record of the customized wager is published to ablockchain ledger (e.g., distributed blockchain ledger). As indicated inthe foregoing description, a transactional record for customized wagermay be added to a block of the blockchain ledger. Flow of the set ofoperations 850 may then proceed to operation 864, where usage of thevirtual good(s) may be locked until an outcome of the customized wageris determined. For instance, the gaming platform may be configured toimplement one or more components that execute processing operations toprevent the virtual good from being utilized while an active wager, thatincludes the virtual good, is pending. Essentially, the virtual good isplaced in escrow until an outcome is reached. In some alternativeexamples, a gaming application/service may still enable access to andusage of the virtual good up until the point in which an outcome hasdisassociated the virtual good (or a portion of the virtual good) fromthe player account.

After a wager has been placed, flow of the set of operations 850 mayproceed to operation 866. In operation 866, an outcome of the customizedwager is determined. Determination of an outcome of the customized wageris described throughout the present disclosure. As an example,determination of the outcome for the customized wager is automaticallyinitiated based on an occurrence of a trigger/triggering event. Forinstance, the trigger event may comprise one or more of a date and atime whereby code may be executed to determine the outcome. Otherexamples of triggering events are subsequently described (e.g., seedescription of FIGS. 11A and 11B). Operation 866 may compriseautomatically determining an outcome of the customized wager byverifying a set of conditions against a validation source (or multiplevalidation sources).

After an outcome of a customized wager is determined, the virtualgood(s) may be unlocked for usage (operation 868). Processing operationsmay be executed to unfreeze usage of the virtual goods for subsequentupdate based on the determined outcome of the customized wager. This mayoccur automatically based on determination (operation 866) of an outcomefor the customized wager. Once the virtual good is available to utilize,either through a locking/unlocking sequence or otherwise available forutilization through the gameplay application/service, flow may proceedto operation 870. At operation 870, one or more actions may be executedto update the virtual good(s). For instance, processing operation 870may comprise executing an action to modify the virtual good(s) based onthe determined outcome of the customized wager. In one example, anexecuted action is an action to transfer a virtual good to anotherplayer account based on the determined outcome of the customized wager.In another example, an executed action is a modification of the virtualgood based on a result of the determined outcome. For instance,attributes of a virtual good may be updated (e.g., increased ordecreased, new attributes added, levels changed) based on the determinedoutcome. In yet another example, an executed action is an action toremove an association of the virtual good from the player account basedon the determined outcome of the customized wager. For instance, aplayer may lose a wager, that wagers a virtual good, where the virtualgood may be transferred to another player account or back to the gamingapplication/service.

FIG. 8C illustrates an example set of operations 880 for utilization ofa distributed multi-ledger architecture that may be utilized for wagercreation involving virtual goods. As identified in the foregoingdescription, transactions related to virtual goods may be managed usinga transaction ledger that is associated with a gaming platform. Forinstance, a blockchain protocol may be implemented to manage a securedistributed ledger (e.g., blockchain ledger), where virtual goods may bemanaged on a transactional basis.

Processing of the set of operations 880 begins at operation 882, wherean interaction with a virtual good is detected. As an example, virtualgood(s) may be accessed during usage (e.g., gameplay) through a gamingapplication/service as well as in instances where a player may wagervirtual goods in a customized bet. Selection and/or interaction with avirtual good through a gaming application/service may trigger access toa transactional record associated with the virtual good (e.g., that isstored in a blockchain ledger). In some alternative examples, virtualgood identification may occur when a player account is accessed, forexample, before a user attempts to access its virtual goods. This mayhelp create an efficient user interface experience for the user so thereis no latency at run time when a player wishes to utilize its virtualgoods.

In any example, flow may proceed to operation 884, where a blockchainledger may be accessed to evaluate the virtual good. For instance, agaming platform may be configured to implement one or more componentsthat programmatically accesses a link to a blockchain ledger to evaluatetransactional data related to the virtual good including attributes,state (e.g., active, locked/unlocked, whether the virtual good istransferrable). That is, detected access to a virtual good (e.g.selection through a gaming application/service) may be a trigger foraccessing a blockchain ledger. In some examples, a specific blockchainledger may be generated that pertains specifically to transactionsinvolving virtual goods, where the blockchain ledger is a virtual goodtracking blockchain ledger. In any case, a blockchain ledger enablessecure access to data and/or metadata associated with the virtual goodto enable quick identification of transactional data for the virtualgood including a block (of a blockchain ledger) in which data for thevirtual good is stored. For example, pointer data may be associated witha virtual good, that can identify pertinent data fields that relate tousage and/or transactional records associated with the virtual good.

Flow of the set of operations 880 may proceed to operation 886, whereattributes of the virtual good(s) are verified. Operation 886 maycomprise dynamically verifying one or more attributes of the virtualgood using a blockchain ledger (e.g., virtual good tracking blockchainledger). For instance, the context of the virtual good includingapplicable data fields may be confirmed so the gamingapplication/service is aware of the most up-to-date context of thevirtual good for usage in a gaming environment. This may be used toverify access to virtual goods and associated properties as well asprovide on-hand data for subsequent transaction processing by a gamingapplication/service. Once the attributes of the virtual good(s) areverified, access to the virtual good, through the gaming environment, isenabled (operation 888).

In most cases, a player may be accessing a virtual good to utilize thevirtual good or take some sort of action (e.g., use the virtual good,modify the virtual good, create a customized wager involving the virtualgood). The set of operations 880 may comprise generation (operation 890)of a transactional query for the virtual good. This may occur based onuser action received through a graphical user interface of a gamingplatform. As an example, operation 890 may generate a transactionalquery, identifying a virtual good, using a private key. The private keymay be associated with a specific player account or group account andprovide an additional level of security for management of virtual goods.Transactional queries may comprise access to virtual goods, modificationof virtual goods and/or including virtual goods as collateral in acustomized wager. Operation 890 may further comprise transmitting thetransaction to one or more nodes of a distributed blockchain network,for example, where the nodes may be used to valid the transactionalquery. In some cases, validation of the transactional query may compriseverifying the private key or other account security data (e.g.,password, biometric authentication). One or more node may process aresponse to the transaction query. Processing of a response to thetransaction query may comprise identifying one or more attributesassociated with the virtual good, for example, that access is beingrequested to.

Some transactional queries may comprise access requests rather thanupdate to a virtual good. Flow of the set of operations 880 may processto decision operation 892, where it is determined whether an update tothe virtual good is associated with a transactional query request. Inexamples where no update occurs to the virtual good (or attributes ofthe virtual good), flow of decision determination 892 branches NO andprocessing remains idle until a new request is made. In instances wherea transactional query comprises a request to update a virtual good, flowof decision determination branches YES and processing proceeds tooperation 894. At operation 894, a new record is created for update tothe virtual goods. A determination is then executed (operation 896) todetermine whether to add the new record to the blockchain ledger.Operations for creation of transactional records and executeddeterminations to validate created records (including creation of newblocks of a blockchain ledger) have been described in the foregoingdescription of the present disclosure.

FIG. 9 illustrates an example of transaction recordation within ablockchain according to some embodiments of the present technology. Asillustrated in FIG. 9 , transactions 910A-910N are occurring at variousgaming terminals. In accordance with various embodiments, a hash may becreated for each entry in the ledger. For example, a SHA (Secure HashAlgorithm) may be used as a cryptographic hash function to create aone-way, (essentially) collision free signature of the entry. TheSHA-256 algorithm generates 256-bit (32-byte) hash. Using hashingfunction 920, hashes are created of these transactions which are thenadded to blocks 940A-940N within the block chain. For example, thefollowing entry may be made into the transaction ledger:

  Transaction ID: 2017Oct23-143856 Machine ID: 1010344568873NV LoyaltyID: [bear37, 100898345] Credits: [$188] Bet: [$5, $10, $11] Activity:[Lives: 2, Ammo: 45, Level: 3, Skill Level: 8]

The output of this entry from hashing function 920 that uses a SHA-256hashing algorithm would be:

-   -   d36b1d6d72d324e476be798de120b25106f8cffbac3a00b1a6de43fa19d6c9f4

This hash value can then be incorporated within the immediatelysubsequent entry to effectively create a tamper proof system asillustrated in FIG. 10 . FIG. 10 illustrates an example of a tamperevident log 1000 that may be used in accordance with various embodimentsof the present technology. In some embodiments, the entry may alsoinclude additional information such as, but not limited to,cryptographic signatures, pointers (e.g., hash pointers) to previoustransactions, GPS coordinates, telephone numbers, IP addresses, e-mailaddresses, user identifiers, international mobile station equipmentidentity (IMEI), mobile equipment identifiers (MEID), integrated circuitcard identifiers (ICCID), part identifiers, software identifiers,current gaming session identifiers, identification of any nearby playerterminals, biometric data, recordings from surveillance systems, cameraor video files, and the like. The first block in the chain can bereferred to as the genesis block since this is the first recordoriginating in the distributed ledger.

FIG. 11A illustrates an example of a set of operations 1100 for creationand management of customized bets in accordance with various embodimentsof the present technology. As illustrated in FIG. 11 , a request toenter a customized bet can be received during receiving operation 1105.Identification operation 1110 can identify any rules or restrictionsneed to be imposed. These rules and restrictions can be used in thecreation of a customized betting contract by creation operation 1115.Rules may be user-defined by players entering into a betting contractand/or defined by gaming platform. In some examples, rules may bespecific to the type of bet and/or wager that is being executed.

The customized betting contract can be presented to all parties forreview during presentation operation 1120. When determination operation1125 determines that any one of the parties does not accept thecontract, then determination operation 1125 branches to creationoperation 1115 where the customized betting contract can be modified(operation 1130). When determination operation 1125 determines that allof the parties have accepted the contract, then determination operation1125 branches to addition operation 1135 where a block is added to theblockchain ledger representing the betting contract. When a customizedbet is created, e.g., by a player through a graphical user interface ofthe gaming application/service, processing to validate the bettingtransaction may be similar to what is described in the foregoingdescription (e.g., see description of FIGS. 8-9 ). For example,processing operations previously described may be utilized to create ablock for addition to a blockchain ledger. A consensus decision, amongstgaming nodes, is executed to validate the addition of a block (thatcomprises data for the customized bet) to a blockchain ledger of thegaming platform. Once a block is validated for addition to theblockchain ledger, flow may proceed to operation 1135, where a block,representing the betting contract, may be added to the blockchainledger. As indicated in the foregoing description, a block comprisesdata for a betting contract but may also include data related to otherbetting contracts (e.g., created by players around the same time).

At operation 1140, fund modification is executed based on the bettingcontract. For instance, player accounts (and any other affiliatedaccounts such as bank accounts) may be updated to hold wagered content,funds (e.g., currency, cryptocurrency), attributes, virtual goods, etc.,while an executed betting contract is pending an outcome. As an example,a representation of the customized bet may be added to a mobile walletcapable of tracking customized bets. The mobile wallet may be acomponent of a gaming application/service or may be a third-partyapplication/service that interfaces with a gaming application/service(e.g., through an application programming interface (API)). Therepresentation includes a pointer to the record created for thecustomized bet in the gaming platform (e.g., distributed multi-ledgerplatform). In other examples, betting may occur with in-game virtualgoods, where players may wager and risk virtual goods such ascharacters, attributes, badges, power-ups, affiliations, rank, etc.

The gaming platform may be configured to automatically execute code todetermine an outcome of a betting contract. For instance, this may occurbased on the occurrence of a triggering event. A triggering event may bespecific data that, upon satisfaction, enables the outcome of a bet tobe determined. In one example, a triggering event may include a specificdate and time upon which an outcome of a bet is able to be verified. Forinstance, a bet may be made between two users over a football game thatoccurs on a specific date and time. However, triggering events are notlimited to time-based examples. Triggering events may comprise any typeof data, non-limiting examples of which comprise but are not limited to:date and/or time-specific data; keywords, conditions; earnedachievements; and level of completion of a task/activity, among otherexamples.

The gaming platform may implement one or more components for executing averification engine that is configured to detect the occurrence of atriggering event as well as validate an outcome of a placed bet. Forinstance, the verification engine may execute pre-programmed code thatis useful to access resources to evaluate parameters of a bettingcontract. As an example, the verification engine is configured to parsedata associated with a record created for a bet. At a later point intime, the verification engine is further configured to executeprocessing operations to confirm an outcome of a bet through thevalidation sources identified in a betting contract. For instance, theverification engine is configured to confirm that conditions/parametersof the bet have been satisfied and further access one or more validationsources to verify the outcome of a bet. A result of that executiondetermines an outcome of the bet.

As referenced in the foregoing, more than one validation source may beutilized to verify a bet, where a consensus may be determined from aplurality of validation sources, leaving less likelihood that adetermined outcome is incorrect. Determination of an outcome comprisesdetermining a winner (operation 1145) of the betting contract. In somealternative instances, it is determined that the conditions of the betare not satisfied or there is no winner (e.g., a tie occurs). In suchcases, a notification may be presented to the players indicating theoutcome and any escrowed funds may be returned to the respective playeraccounts. In some embodiments, the determination operation 1145 (used todetermine a winner of a bet) may determine whether the game/bet is aplayer vs. machine, person vs. casino/bookmaker, person vs. person,tournament play, etc. Based on this information of the parties involved,different rules and/or regulations may apply. In addition, rake amounts,selection of payout currencies and/or prizes, bonus rounds, and theother events or charges may be based on the player configuration. Inaddition, this information indicates who will be responsible for thebet. For example, a determination can be made as to whether thecasino/bookmaker is holding the bet or whether the bet is being held bya third party (e.g., in a peer to peer bet).

In examples where a winner is determined from a bet, payout amounts aredistributed (operation 1150) to the player account of the player who wonthe bet. Payout can occur with anything of value such as, but notlimited to specific currencies (e.g., US dollars/money), cryptocurrencies such as Bitcoin, virtual currencies, physical prizes, virtualgoods and the like. Player accounts may be automatically updated inresponse to determination of an outcome of a bet.

Example 1—Sports Bet

Example would be Jordan and Jason bet on the Super Bowl. Jason choosesMiami Dolphins and Jordan chooses Denver Broncos to win. The contractwould be in place holding the money. Automatically, at end of Super Bowlwhoever the determined winner would be paid per the instructions of thesmart contract. The smart contract processes the bet and returns the windirectly to winner's wallet. This bet can be on a public or privateblockchain and is verified code, that lives on the very public/privateblockchain.

Example 2—Game of Chance Random Bet

Example would be if a player bets on different games such as roulette orcraps where an algorithm is used. If In a game of craps player bets onsnake eyes (each dice lands on one) than the contract would pay based onodds of 30:1 so if player bet $5 on snake eyes and the dice landed onsnake eyes the player would get paid $150. The distributed ledger wouldshow the bet made, odds on bet, what occurred when dice algorithmicallywhere thrown (end result) and win/loss and credit to wallet or credit tocasino.

Example 3—Prediction Bet

Example would be betting on who will be the next President of the UnitedStates, who will win American Idol or some other sort of social,political or economic event that will occur in the future. If Jason betsthat Mark Cuban will be the next President of the United States andJordan chooses the next President will be Steve Bannon both of whichrunning on the Republican ticket than odds are established for reachbet. The casino or bookmaker who took the bet would establish odds basedon a future event and its outcome. If Jason is correct than his moneywould be automatically transferred to his wallet. If Jordan was correctthan his bet would automatically be transferred to his wallet. Thebookmaker would hold the money bet by both Jordan and Jason. Theirwallet would be ultimately responsible for payout which would occurautomatically. Now if the bet was made peer to peer or between Jordanand Jason directly than whoever wins the bet would automatically havethat money bet sent to their respective wallet. If for example SteveBannon does not run for president than Jordan would automatically loseas Steve Bannon never ran in the first place.

FIG. 11B illustrates a continued example of a set of operations 1160 forcreation and management of customized bets in accordance with variousembodiments of the present technology. FIG. 11B provides operations thatmay follow distribution of a payout amount (operation 1150 of FIG. 11A).Similar to instances where a record of a customized bet is created andadded to a blockchain ledger, additional transactional records may becreated and added, to a blockchain ledger, when an outcome of a bet isdetermined, and payout issued.

At operation 1165, a record for a payout transaction is published foraddition to a blockchain ledger. Record creation, such as creation of ablock for a blockchain ledger, and publication of records have beendescribed in the foregoing description. The published record may bebroadcast (operation 1170) to gaming nodes for validation as to whetherto add the record to the blockchain ledger. For instance, a block thatcomprises the transaction record for payout may be created and publishedfor validation. A consensus determination (determination operation 1175)may be executed by a subset of gaming nodes to determine whether to addthe block to the blockchain ledger. Examples of consensus determinationprocessing has been provided in the foregoing description. In exampleswhere the block is not validated, flow of determination operation 1175branches NO and the set of operations 1160 proceeds to operation 1180.At operation 1180, a request is made to a local storage to rebroadcastreceive the created record, where the created record is rebroadcast,from a gaming node that created the record, to other gaming nodes forexecution of a consensus determination. In some alternative examples, arecord for a payout transaction is re-created as there may have been anerror in generation of a block that comprises the payout transaction.Flow of the set of operations 1160 may then return to operation 1165,where the record is re-published or recreated. In examples where aconsensus determination validates a block that comprises the record ofthe payout transaction, determination operation 1175 branches YES andprocessing of the set of operation 1160 proceeds to operation 1185. Atoperation 1185, the record (e.g., block) of the payout transaction isadded to the blockchain ledger.

FIG. 12 illustrates a non-limiting example 1200 of information that maybe recorded in a multi-ledger system in accordance with one or moreembodiments of the present technology. Blockchain technology allows anetwork of computers to agree at regular intervals on the true state ofa distributed ledger. Multiple different ledgers may be kept, based onvarious purposed. FIG. 12 represents one example 1200, where informationsuch as transaction identifiers, payer identifiers, betting amounts,location identifiers, payout amounts, and other information (e.g.,executable code) can be stored. The blockchain may use hashingalgorithms (e.g., SHA 256) along with random number generators and othertechnology to secure the ledger. As identified in the foregoingdescription, a ledger may further comprise additional fields (not shown)that relate to customized parameters associated with a specific bet.

FIG. 13 illustrates a non-limiting example of a graphical user interface1300 that may be used for selecting games in accordance with someembodiments of the present technology. Some embodiments of the presenttechnology can utilize graphical user interface 1300 to access games andto perform system level functions such as deposits and cash-outs.Through the client device, the graphical user interface 1300 can providea visually consistent, intuitive and flexible framework for delivering afull gamut of gaming experiences. Client navigation can be based on aneasily traversable hierarchy: a player selects a game, is taken to thatgame's lobby, and then chooses a table, match or tournament. Interfacequeues including transition animations and sounds help players moveeffortlessly through the navigational structure. As illustrated in FIG.13 , graphical user interface 1300 provides quick access to anextensible menu of games. Each game link can display real-timeinformation about the game such as active players, tables andtournaments. Some embodiments may include a custom bet link thatfacilitates the creation of customized bets that can be stored in theledger as a smart contract between a player and another part (e.g., thecasino, another player, sports book, etc.).

FIG. 14 illustrates a non-limiting example of a graphical user interface1400 that may be used for selecting options to identify suitable gamesin accordance with various embodiments of the present technology. Thegraphical user interface 1400 shown in FIG. 14 can display game lobbiesincluding sort and filter functions. A quick-seat tool can let playersquickly find a suitable seat in table based games by using a 2-4 stepwizard-style process. At the operator's discretion games can be enabledfor simultaneous multi-game play and can support wait-listing. Someembodiments provide for seamless transition between multiple gamesincluding alert and auto-switch features that notify a player whenaction is required or automatically brings a game that needs attentionto the forefront. Some embodiments use vector based graphics technologyresulting in minimal file sizes and an interface that can scale smoothlyto a wide range of resolutions. Some client devices can support rastergraphics including embedded and streaming video. Colors, fonts,background images and even sounds (e.g., within Arrow Client) can becustomized for (or by) an operator or even for a given machine or bankof machines.

FIG. 15 illustrates a non-limiting example of a graphical user interface1500 for showing available games in accordance with one or moreembodiments of the present technology. Graphical user interface 1500shows a main display of an adapted user interface that enables playersto create customized bets (e.g., user interface element 1510) through agaming platform. A player may select user interface element 1510 toinitiate creation of a customized bet, which may prompt the player withan additional user interface screen to enter customized parametersassociated with bet creation. A non-limiting example of another userinterface screen for entering customized bets is provided in FIG. 15 .Graphical user interface 1500 further comprises a user interface elementfor available game selection 1520. The user interface element foravailable game selection 1520 is configured to display available gamesthat the user can access through a gaming platform. The graphical userinterface 1500 may update the user interface element for available gameselection 1520, for example, to display games that the player has showna preference for and/or rotating display of games to identify new gamesfor the player. Additionally, the graphical user interface 1500 maycomprise additional user interface elements such as gaming managementuser interface elements 1530. Gaming management user interface elementsmay comprise user interface features that enable a user to directlyaccess specific features such as: login/sign-in, account information,advertising and promotions, betting history; and access to a digitalwallet, among other examples.

FIG. 16 illustrates various examples of graphical user interfaces 1600showing lobbies for various games according to some embodiments of thepresent technology. The examples shown in FIG. 16 are non-limitingexamples of lobbies for specific types of games such as poker, 9-balland Sudoku. However, similar types of game lobbies may be created forany game offered through a gaming platform. Example game lobbies maycomprise data for categorized levels of gaming for a specific type ofgame (e.g., low and high stakes poker). Specific data related to a levelof gaming (e.g., selected table or match through a gaming lobby) may beidentified in transactional data that is used to create a record ofplayer activity, bets, wagers, etc. Such data may be identified intransactional record that is included in a block, which is added to ablockchain ledger.

FIG. 17 illustrates an example of a graphical user interface 1700 forcreating customized bets that may be stored and automatically executedwithin a distributed multi-ledger system according to variousembodiments of the present technology. As illustrated in FIG. 17 , auser can access a custom betting interface (e.g., via a player terminal,mobile phone, smart television, etc.) and create a custom bet. The betmay be with the casino, another individual, an event, or other party.Once selected, the player can enter specific customizable informationfor the bet. For example, the player may select to create a sports betwith another player on whether an NFL team will win the super bowl in aparticular year (e.g., 2020). As another example, a player can create a$100 customized bet on a specific video game (e.g., Pac-Man) either withanother player or to beat a particular score (e.g., a one-time score, anaverage score over a day, week, or month, etc.). The game can be played(e.g., on a player terminal or user device) and the score set by theplayer can be recorded to a blockchain 1720. In some cases, the samerandom number or other gaming parameters can be stored in the blockchain1720 and retrieved so that the players are truly playing the same game.The competing player can play and the corresponding score can berecorded and a winner determined.

In some embodiments, a bet could be cancelled, etc. One or morevalidation sources can be selected which will be used to verify theresults. A rules engine 1710, interfaces with a gaming platform and ablockchain protocol, that is used for generation of blockchain 1720. Therules engine 1710 comprises one or more components (e.g., hardware,software or a combination thereof) that ensures that the customized betis legal and in compliance with any rules or regulations. The rulesengine 1710 is further configured to execute processing operations thattranslate the customized bet into a contract 1730 (e.g., smartcontract), which can be stored on as one or more blocks of a blockchain1720. The betting amounts can be placed in escrow, where funds may beremoved from a digital wallet of a player while a bet is pending. Therecould be multiple places or source that confirm the wager. The rulesengine 1710 may further be configured to provide trust levels orrankings so that those validation sources with a higher ranking wouldagree in view of a conflict. Other embodiments may use a majority rule,additional verification, or submission to a human for resolution. Onebenefit of this type of various embodiments is that no intermediary isneeded. Instead, some embodiments allow for customized creation,tracking and payout bets without a third-party human. Key data that isselected and agreed to between parties can be automatically verified andtracked. A customized betting contract can be created and stored ablockchain based on events at a specific time and date and who won orlost determines the payout. For sweepstakes or tournament, there couldbe a lot of winners. For example, everybody participant could pay $100entry fee and only the top ten will get paid. Results can be put onblock chain 1720 so everyone can see how they score. An exemplarycontract 1730 may comprise transactional data for a customized betincluding but not limited to: the parties (e.g., player accountsassociated with a bet), triggering event(s), timestamp data, escrowdata, status, conditions; and number of bets and associated terms (e.g.,parlay bet), among other examples.

Exemplary Computer System Overview

Aspects and implementations of the gaming system of the disclosure havebeen described in the general context of various steps and operations. Avariety of these steps and operations may be performed by hardwarecomponents or may be embodied in computer-executable instructions, whichmay be used to cause a general-purpose or special-purpose processor(e.g., in a computer, server, cloud-based gaming platform or othercomputing device) programmed with the instructions to perform the stepsor operations. For example, the steps or operations may be performed bya combination of hardware, software, and/or firmware.

FIG. 18 is a block diagram illustrating an example machine representingthe computer systemization of the host computer system. The gamingcontroller 1800 may be in communication with entities including one ormore users 1825 client/terminal devices 1820 (e.g., devices 110), userinput devices 1805, peripheral devices 1810, optional co-processordevice(s) (e.g., cryptographic processor devices) 1815, and networks1830. Users may engage with the gaming controller 1800 via terminaldevices 1820 over networks 1830. In some embodiments, all or a portionof the communications between terminal devices 1820 and gamingcontroller 1800 can be encrypted. Various laws, standards, or bestpractices may require cryptography for storing, transmitting, and/orutilization of various types data, information, code, signaling, etc.

Computers may employ central processing units (CPUs) or processors toprocess information. Processors may include programmable general-purposeor special-purpose microprocessors, programmable controllers,application-specific integrated circuits (ASICs), programmable logicdevices (PLDs), embedded components, a combination of such devices andthe like. Processors execute program components in response to userand/or system-generated requests. One or more of these components may beimplemented in software, hardware or both hardware and software.Processors pass instructions (e.g., operational and data instructions)to enable various operations.

The gaming controller 1800 may include clock 1865, CPU 1870, memory suchas read only memory (ROM) 1885 and random-access memory (RAM) 1880 andco-processor 1875 among others. These controller components may beconnected to a system bus 1860, and through the system bus 1860 to aninterface bus 1835. Further, user input devices 1805, peripheral devices1810, co-processor devices 1815, and the like, may be connected throughthe interface bus 1835 to the system bus 1860. The interface bus 1835may be connected to a number of interface adapters such as processorinterface 1840, input output interfaces (I/O) 1845, network interfaces1850, storage interfaces 1855, and the like.

Processor interface 1840 may facilitate communication betweenco-processor devices 1815 and co-processor 1875. In one implementation,processor interface 1840 may expedite encryption and decryption ofrequests or data. Input output interfaces (I/O) 1845 facilitatecommunication between user input devices 1805, peripheral devices 1810,co-processor devices 1815, and/or the like and components of gamingcontroller 1800 using protocols such as those for handling audio, data,video interface, wireless transceivers, or the like (e.g., Bluetooth®,IEEE 894a-b, serial, universal serial bus (USB), Digital VisualInterface (DVI), 802.11a/b/g/n/x, cellular, etc.). Network interfaces1850 may be in communication with the network 1830. Through the network1830, gaming controller 1800 may be accessible to remote terminaldevices 1820 (e.g., player terminals 110 illustrated in FIG. 1 ).Network interfaces 1850 may use various wired and wireless connectionprotocols such as, direct connect, Ethernet, wireless connection such asIEEE 802.11a-x, miracast and the like. Some components of theinteractive gaming system may include various protocols or comply withvarious standards or certifications set forth by different associationsor regulatory agencies. For example, some embodiments may use the slotaccounting system (SAS) protocol or comply with the game to system (G2S)standard.

Examples of network 1830 include the Internet, Local Area Network (LAN),Metropolitan Area Network (MAN), a Wide Area Network (WAN), wirelessnetwork (e.g., using Wireless Application Protocol WAP), a securedcustom connection, and the like. The network interfaces 1850 can includea firewall which can, in some aspects, govern and/or manage permissionto access/proxy data in a computer network, and track varying levels oftrust between different machines and/or applications. The firewall canbe any number of modules having any combination of hardware and/orsoftware components able to enforce a predetermined set of access rightsbetween a particular set of machines and applications, machines andmachines, and/or applications and applications, for example, to regulatethe flow of traffic and resource sharing between these varying entities.The firewall may additionally manage and/or have access to an accesscontrol list which details permissions including, for example, theaccess and operation rights of an object by an individual, a machine,and/or an application, and the circumstances under which the permissionrights stand. Other network security functions performed or included inthe functions of the firewall, can be, for example, but are not limitedto, intrusion-prevention, intrusion detection, next-generation firewall,personal firewall, etc., without deviating from the novel art of thisdisclosure.

Storage interfaces 1855 may be in communication with a number of storagedevices such as, storage devices 1890, removable disc devices, and thelike. The storage interfaces 1855 may use various connection protocolssuch as Serial Advanced Technology Attachment (SATA), IEEE 894,Ethernet, Fiber, Universal Serial Bus (USB), and the like. A storagesystem/device may be a component of a computing system that is executedprocessing operations as described herein or alternativelyconnecting/interfacing with a computing system via cabled or wirelessnetwork connection. An example storage system may comprise volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information, such as computer readableinstructions, data structures, program modules, cache memory or otherdata. Storage systems/devices may be configured to storecomputer-readable storage media. Examples of computer-readable storagemedia include but are not limited to: random access memory, read onlymemory, magnetic disks, optical disks, flash memory, virtual memory andnon-virtual memory, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or other suitable storagemedia, except for propagated signals. In no case is thecomputer-readable storage media a propagated signal.

In addition to computer readable-storage media, in some implementationsstorage devices may also include computer readable communication mediaover which at least some software may be communicated internally orexternally. Storage systems may be implemented as a single storagedevice but may also be implemented across multiple storage devices orsub-systems co-located or distributed relative to each other. Storagesystems may comprise additional elements, such as a controller, capableof communicating with processing systems or possibly other systems.Software may be implemented in program instructions and among otherfunctions may, when executed by processing systems (e.g., processors,computing devices). For example, software may include programinstructions for implementing processing operations described hereinrelated to gaming application/service execution and managementincluding: customized betting/wager management; blockchain ledgermanagement; management of gaming nodes and player accounts; and virtualgood creation, tracking and management, among other examples.

In particular, the program instructions may include various componentsor modules that cooperate or otherwise interact to carry out the variousprocesses and operational scenarios described herein. The variouscomponents or modules may be embodied in compiled or interpretedinstructions, or in some other variation or combination of instructions.The various components or modules may be executed in a synchronous orasynchronous manner, serially or in parallel, in a single threadedenvironment or multi-threaded, or in accordance with any other suitableexecution paradigm, variation, or combination thereof. Software mayinclude additional processes, programs, or components, such as operatingsystem software, virtual machine software, or other applicationsoftware. Software may also comprise firmware or some other form ofmachine-readable processing instructions executable by processingsystem. In general, software may, when loaded into processing system andexecuted, transform a suitable apparatus, system, or device overall froma general-purpose computing system into a special-purpose computingsystem customized to process data and respond to queries. Indeed,encoding software on a storage system may transform the physicalstructure of storage system. The specific transformation of the physicalstructure may depend on various factors in different implementations ofthis description. Examples of such factors may include, but are notlimited to, the technology used to implement a computer-readable storagemedia and whether the computer-readable storage media are characterizedas primary or secondary storage, as well as other factors.

User input devices 1805 and peripheral devices 1810 may be connected toI/O interface 1845 and potentially other interfaces, buses and/orcomponents. User input devices 1805 may include card readers, fingerprint readers, joysticks, keyboards, microphones, mouse, remotecontrols, retina readers, touch screens, sensors, and/or the like.Peripheral devices 1810 may include antenna, audio devices (e.g.,microphone, speakers, etc.), cameras, external processors, communicationdevices, radio frequency identifiers (RFIDs), scanners, printers,storage devices, transceivers, and/or the like. Co-processor devices1815 may be connected to the controller 1800 through interface bus 1835,and may include microcontrollers, processors, interfaces or otherdevices.

Computer executable instructions and data may be stored in memory (e.g.,registers, cache memory, random access memory, flash, etc.) which isaccessible by processors. These stored instruction codes (e.g.,programs) may engage the processor components, motherboard and/or othersystem components to perform desired operations. The controller 1800 mayemploy various forms of memory including on-chip CPU memory (e.g.,registers), RAM 1880, ROM 1885, and storage devices 1890. Storagedevices 1890 may employ any number of tangible, non-transitory storagedevices or systems such as fixed or removable magnetic disk drive, anoptical drive, solid state memory devices and other processor-readablestorage media. Computer-executable instructions stored in the memory mayinclude an interactive gaming platform having one or more programmodules such as routines, programs, objects, components, datastructures, and so on that perform particular tasks or implementparticular abstract data types. For example, the memory may containoperating system (OS) component 1895, modules and other components,database tables, and the like. These modules/components may be storedand accessed from the storage devices, including from external storagedevices accessible through an interface bus 1835.

The database components can store programs executed by the processor toprocess the stored data. The database components may be implemented inthe form of a database that is relational, scalable and secure. Examplesof such database include DB2, MySQL, Oracle, Sybase, and the like.Alternatively, the database may be implemented using various standarddata-structures, such as an array, hash, list, stack, structured textfile (e.g., XML), table, and/or the like. Such data-structures may bestored in memory and/or in structured files.

The gaming controller 1800 may be implemented in distributed computingenvironments, where tasks or modules are performed by remote processingdevices, which are linked through a communications network, such as aLocal Area Network (“LAN”), Wide Area Network (“WAN”), the Internet, andthe like. In a distributed computing environment, program modules orsubroutines may be located in both local and remote memory storagedevices. Distributed computing may be employed to load balance and/oraggregate resources for processing. Alternatively, aspects of the gamingcontroller 1800 may be distributed electronically over the Internet orover other networks (including wireless networks). Those skilled in therelevant art(s) will recognize that portions of the interactive gamingsystem may reside on a server computer, while corresponding portionsreside on a client computer. Data structures and transmission of dataparticular to aspects of the gaming controller 1800 are also encompassedwithin the scope of the disclosure.

CONCLUSION

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense, as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to.” As used herein, the terms “connected,”“coupled,” or any variant thereof means any connection or coupling,either direct or indirect, between two or more elements; the coupling orconnection between the elements can be physical, logical, or acombination thereof. Additionally, the words “herein,” “above,” “below,”and words of similar import, when used in this application, refer tothis application as a whole and not to any particular portions of thisapplication. Where the context permits, words in the above DetailedDescription using the singular or plural number may also include theplural or singular number respectively. The word “or,” in reference to alist of two or more items, covers all of the following interpretationsof the word: any of the items in the list, all of the items in the list,and any combination of the items in the list.

The above Detailed Description of examples of the technology is notintended to be exhaustive or to limit the technology to the precise formdisclosed above. While specific examples for the technology aredescribed above for illustrative purposes, various equivalentmodifications are possible within the scope of the technology, as thoseskilled in the relevant art will recognize. For example, while processesor blocks are presented in a given order, alternative implementationsmay perform routines having steps, or employ systems having blocks, in adifferent order, and some processes or blocks may be deleted, moved,added, subdivided, combined, and/or modified to provide alternative orsubcombinations. Each of these processes or blocks may be implemented ina variety of different ways. Also, while processes or blocks are attimes shown as being performed in series, these processes or blocks mayinstead be performed or implemented in parallel, or may be performed atdifferent times. Further, any specific numbers noted herein are onlyexamples: alternative implementations may employ differing values orranges.

Having described several embodiments, it will be recognized by those ofskill in the art that various modifications, alternative constructions,and equivalents may be used without departing from the spirit of thetechnology. Additionally, a number of well-known processes and elementshave not been described in order to avoid unnecessarily obscuring thepresent technology. Accordingly, the above description should not betaken as limiting the scope of the technology, which is defined in thefollowing claims.

The teachings of the technology provided herein can be applied to othersystems, not necessarily the system described above. The elements andacts of the various examples described above can be combined to providefurther implementations of the technology. Some alternativeimplementations of the technology may include not only additionalelements to those implementations noted above, but also may includefewer elements.

These and other changes can be made to the technology in light of theabove Detailed Description. While the above description describescertain examples of the technology, and describes the best modecontemplated, no matter how detailed the above appears in text, thetechnology can be practiced in many ways. Details of the system may varyconsiderably in its specific implementation, while still beingencompassed by the technology disclosed herein. As noted above,particular terminology used when describing certain features or aspectsof the technology should not be taken to imply that the terminology isbeing redefined herein to be restricted to any specific characteristics,features, or aspects of the technology with which that terminology isassociated. In general, the terms used in the following claims shouldnot be construed to limit the technology to the specific examplesdisclosed in the specification, unless the above Detailed Descriptionsection explicitly defines such terms. Accordingly, the actual scope ofthe technology encompasses not only the disclosed examples, but also allequivalent ways of practicing or implementing the technology under theclaims.

To reduce the number of claims, certain aspects of the technology arepresented below in certain claim forms, but the applicant contemplatesthe various aspects of the technology in any number of claim forms. Forexample, while only one aspect of the technology is recited as acomputer-readable medium claim, other aspects may likewise be embodiedas a computer-readable medium claim, or in other forms, such as beingembodied in a means-plus-function claim. Any claims intended to betreated under 35 U.S.C. § 112(f) will begin with the words “means for”,but use of the term “for” in any other context is not intended to invoketreatment under 35 U.S.C. § 112(f). Accordingly, the applicant reservesthe right to pursue additional claims after filing this application topursue such additional claim forms, in either this application or in acontinuing application.

What is claimed is:
 1. An apparatus comprising: one or more computerreadable storage media; one or more processing systems in communicationwith the one or more computer readable storage media; and programinstructions stored on the one or more computer readable storage media,wherein the program instructions, when executed by the one or moreprocessing systems, direct the one or more processing systems to: detectan interaction in the form of a customized wager with a non-fungibletoken (NFT) within a gaming environment; responsive to the interactionwith the NFT being detected, access an NFT tracking blockchain ledger;verify one or more attributes of the NFT using the NFT trackingblockchain ledger; execute a determination to add a new record for theinteraction to the NFT tracking blockchain ledger, wherein thedetermination is made by a consensus decision between a subset ofmultiple nodes of a distributed blockchain network associated with theNFT tracking blockchain ledger; and publish the new record of thecustomized wager to the distributed blockchain network when the subsetof multiple nodes reaches the consensus decision to add the new recordto the NFT tracking blockchain ledger.
 2. The apparatus of claim 1,wherein to verify the one or more attributes of the NFT the programinstructions, when executed by the one or more processing systems, isfurther directs the one or more processing systems to: generate atransaction query using a private key, wherein the transaction queryidentifies the NFT; transmit the transaction query to one or more nodesin a distributed blockchain network; and process a response to thetransaction query to identify the one or more attributes of the NFT. 3.The apparatus of claim 1, wherein the distributed blockchain networkcomprises at least one of: a public blockchain, a private blockchain, asemi-private blockchain, and a hybrid blockchain.
 4. The apparatus ofclaim 1, wherein the interaction is a selection of the NFT forimplementation in the gaming environment.
 5. The apparatus of claim 1,wherein the interaction further comprises a modification of the NFT as aresult of the customized wager.
 6. The apparatus of claim 5, wherein theconsensus decision further comprises validation of one or more of:biometric authentication of an owner of the NFT, authentication of imagedata associated with the owner, authentication of video data associatedwith the owner, and authentication of audio data associated with theowner.
 7. The apparatus of claim 5, wherein the consensus decisioncomprises: a validation of a cryptographic hash, associated with amodification of the NFT, by the subset of the multiple nodes; and aconfirmation that the new record has not already been added to the NFTtracking blockchain ledger.
 8. The apparatus of claim 7, wherein thecryptographic hash comprises values generated based onattribute-specific data fields associated with the NFT, and wherein theconsensus decision comprises validation of a cryptographic puzzleassociated with cryptographic hash.
 9. The apparatus of claim 1, whereinwhen executed by the one or more processing systems the programinstructions further direct the one or more processing systems to:automatically determine an outcome of the customized wager by verifyinga set of conditions against a validation source, wherein the customizedwager is automatically determined based on a trigger event thatcomprises one or more of a date and a time; and execute an action basedfor the NFT based on the outcome of the customized wager.
 10. A methodcomprising: detecting an interaction in the form of a customized wagerwith a non-fungible token (NFT) within a gaming environment; in responseto detecting the interaction in the form of a customized wager with theNFT, accessing an NFT tracking blockchain ledger; verifying one or moreattributes of the NFT using the NFT tracking blockchain ledger; executea determination to add a new record for the interaction to the NFTtracking blockchain ledger, wherein the determination is made by aconsensus decision between a subset of multiple nodes of a distributedmulti-ledger platform associated with the NFT tracking blockchainledger; and publish the new record of the customized wager to the NFTtracking blockchain ledger when the subset of multiple nodes reaches theconsensus decision to add the new record to the NFT tracking blockchainledger.
 11. The method of claim 10, further comprising: generating atransaction query using a private key, wherein the transaction queryidentifies the NFT; transmitting the transaction query to one or morenodes in a distributed blockchain network; and processing a response tothe transaction query to identify the one or more attributes of the NFT.12. The method of claim 10, wherein the interaction is a selection ofthe NFT for implementation in online gameplay.
 13. The method of claim10, wherein the interaction further comprises a modification of the NFTas a result of the customized wager.
 14. The method of claim 13, whereinthe consensus decision further comprises validation of one or more of:biometric authentication of an owner of the NFT, authentication of imagedata associated with the owner; authentication of video data associatedwith the owner, and authentication of audio data associated with theowner.
 15. The method of claim 13, wherein the consensus decisioncomprises: a validation of a cryptographic hash, associated with amodification of the NFT, by the subset of the multiple nodes; and aconfirmation that the new record has not already been added to the NFTtracking blockchain ledger.
 16. The method of claim 15, wherein thecryptographic hash comprises values generated based onattribute-specific data fields associated with the NFT, and wherein theconsensus decision comprises validation of a cryptographic puzzleassociated with cryptographic hash.
 17. The method of claim 10, furthercomprising: automatically determining an outcome of the customized wagerby verifying a set of conditions against a validation source, whereinthe customized wager is automatically determined based on a triggerevent that comprises one or more of a date and a time; and executing anaction based for the NFT based on the outcome of the customized wager.18. One or more non-transitory computer readable media having programinstructions stored thereon which, when executed by one or moreprocessing systems, cause a machine to: detect an interaction in theform of a customized wager with a non-fungible token (NFT) within agaming environment; responsive to the interaction in the form of acustomized wager with the NFT being detected, access an NFT trackingblockchain ledger; verify one or more attributes of the NFT using theNFT tracking blockchain ledger; execute a determination to add a newrecord for the interaction to the NFT tracking blockchain ledger,wherein the determination is made by a consensus decision between asubset of multiple nodes associated with the NFT tracking blockchainledger; and publish the new record of the customized wager to the NFTtracking blockchain ledger when the subset of multiple nodes reaches theconsensus decision to add the new record to the NFT tracking blockchainledger.